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Description 

SYSTEM AND METHOD FOR SECURING 
SENSITIVE INFORMATION DURING 
COMPLETION OF A TRANSACTION 

Cross Reference to Related Applications 

[0001] This invention is a continuation in part of, and claims pri- 
ority to U.S. Patent Application No. 10/192,488, entitled 
"SYSTEM AND METHOD FOR PAYMENT USING RADIO FRE- 
QUENCY IDENTIFICATION IN CONTACT AND CONTACT- 
LESS TRANSACTIONS," filed on July 9, 2002 (which itself 
claims priority to U.S. Provisional Patent Application No. 
60/304,216, filed July 10, 2001), and to U.S. Patent Appli- 
cation No. 10/340,352, entitled "SYSTEM AND METHOD 
FOR INCENTING PAYMENT USING RADIO FREQUENCY 
IDENTIFICATION IN CONTACT AND CONTACTLESS TRANS- 
ACTIONS," filed January 10, 2003 (which itself claims pri- 
ority to U.S. Provisional Patent Application No. 
60/396,577, filed July 16, 2002), all of which are incorpo- 
rated herein by reference. 



Field of Invention 

[0002] This invention generally relates to securing a transaction 
involving radio frequency identification (RFID) technology. 
More particularly, the invention pertains to a system and 
method for securing the RFID enabled transaction using a 
code or number which hides the underlying payment de- 
vice information from the merchant system. 
Background of Invention 

[0003] |_j|< e barcode and voice data entry, RFID is a contactless 
information acquisition technology. RFID systems are 
wireless, and are usually extremely effective in hostile en- 
vironments where conventional acquisition methods often 
fail. RFID has established itself in a wide range of markets, 
such as, for example, the high-speed reading of railway 
containers, tracking moving objects such as livestock or 
automobiles, and retail inventory applications. As such, 
RFID technology has become a primary focus in auto- 
mated data collection, identification and analysis systems 
worldwide. 

[0004] of late, companies are increasingly embodying RFID data 
acquisition technology in a fob or tag for use in complet- 
ing financial transactions. A typical RFID fob is ordinarily a 



self-contained device, which may take the shape of any 
portable form factor. The RFID fob may include a 
transponder for transmitting information during a trans- 
action. In some instances, a battery may be included in 
the fob to power the transponder, in which case the inter- 
nal circuitry of the fob (including the transponder) may 
draw its operating power from the battery power source. 
Alternatively, the fob may gain its operating power di- 
rectly from an RF interrogation signal. U.S. Patent No. 
5,053,774, issued to Schuermann, describes a typical 
transponder RF interrogation system which may be found 
in the prior art. The Schuermann patent generally de- 
scribes the powering technology surrounding conven- 
tional transponder structures. U.S. Patent No. 4,739,328 
discusses a method by which a conventional transponder 
may respond to a RF interrogation signal. Other typical 
modulation techniques which may be used include, for 
example, ISO/IEC 14443 and the like. 
[0005] | n the conventional fob powering technologies used, the 
fob is typically activated upon presenting the fob into an 
interrogation signal. In this regard, the fob may be acti- 
vated irrespective of whether the user desires such activa- 
tion. Alternatively, the fob may have an internal power 



source such that interrogation by the reader for activation 
of the fob is not required. 
[0006] one of the more visible uses of the RFID technology is the 
introduction of Exxon/Mobil's Speedpass® and Shell's 
EasyPay® products. These products use transponders, 
placed in a fob or tag, which enable automatic identifica- 
tion of the user when the fob is presented at a merchant's 
Point of Sale (POS) device, for example, when attempting 
to complete a transaction. During the transaction comple- 
tion, information from the RFID fob is ordinarily passed to 
the POS, which delivers the information to a merchant 
system. 

[0007] jo complete the transaction, fob identification data typi- 
cally may be passed to a third-party server database. The 
third-party server may reference the identification data to 
a customer (e.g., user) credit or debit account. In an ex- 
emplary processing method, the third-party server may 
seek authorization for the transaction by passing the 
transaction and account data to an authorizing entity, 
such as for example an "acquirer" or account issuer. Once 
the server receives authorization from the authorizing en- 
tity, the authorizing entity sends clearance to the POS de- 
vice for completion of the transaction. 



[0008] | n addition to sending the information to an issuer system 
for verification, the merchant system may store the infor- 
mation in a merchant system database for later reference. 
For example, where the transaction device user is a repeat 
customer, the transaction device user may wish to com- 
plete the transaction using transaction account informa- 
tion previously submitted to the merchant system. Since 
the account information is stored on the merchant sys- 
tem, the user need not provide the information to a mer- 
chant to complete subsequent transactions. Instead, the 
user may indicate to the merchant to use the transaction 
account information stored on the merchant system for 
transaction completion. 

[0009] | n another typical example, the merchant system may 

store the transaction account information for later refer- 
ence when the transaction device user establishes a "recur- 
ring billing" account. In this instance, the merchant may 
periodically charge a user for services rendered or goods 
purchased. The user may authorize the merchant system 
to seek satisfaction of the bill using the transaction ac- 
count information. The merchant may thereby send a 
transaction request regarding the bill to an account 
provider, or a third-party server. 



[0010] To lessen the financial impact of fraudulent transactions 
in the RFID environment, fob issuers have focused much 
effort on securing RFID transactions. Many of the efforts 
have focused on securing the transaction account or re- 
lated data during transmission from the user to the mer- 
chant, or from the merchant to third-party server or ac- 
count provider system. For example, one conventional 
method for securing RFID transactions involves requiring 
the device user to provide a secondary form of identifica- 
tion during transaction completion. The RFID transaction 
device user may be asked to enter a personal identifica- 
tion number (PIN) into a keypad. The PIN may then be ver- 
ified against a number associated with the user or the 
RFID transaction device, wherein the associated number is 
stored in an account issuer database. If the PIN number 
provided by the device user matches the associated num- 
ber, then the transaction may be cleared for completion. 

[0011] one problem with the issuer's efforts in securing RFID 

transactions is that they typically do not focus on the ways 
to guard the transaction account information stored on 
the merchant system from theft. As noted, the merchant 
may typically store on a merchant database the informa- 
tion received from the transaction device during a trans- 



action. Such information may be sensitive information 
concerning the fob user or the fob user's account. Should 
the fob user's sensitive information be retrieved from the 
merchant system without authorization, the fob user or 
issuer may be subjected to fraudulent activity. The ability 
to secure the sensitive information stored on the mer- 
chant system is limited by the security measures taken by 
the merchant in securing its merchant system database. 
Consequently, the account provider often has little influ- 
ence over the security of the account information once the 
information is provided to the merchant system. 
[0012] As such, a need exists for a method of securing sensitive 
transaction account information which permits the ac- 
count provider to have a significant influence on the secu- 
rity of the fob user information stored on a merchant sys- 
tem. A suitable system may secure the sensitive informa- 
tion irrespective of the merchant system. 
Summary of Invention 

[0013] a system and method for securing transactions is de- 
scribed which addresses the problems found in conven- 
tional transaction securing methods. The securing method 
described herein includes providing a proxy code to a 
merchant system during a transaction instead of providing 



sensitive transaction account information. A transaction 
device in accordance with the invention provides the 
proxy code to the merchant system contemporaneously 
with a transaction request. The merchant system may re- 
ceive the proxy code and correlate the proxy code to a 
user or transaction in the merchant system. The merchant 
system may store the proxy code in a merchant database 
for later reference. 

[0014] The proxy code does not include any sensitive information 
about the transaction device user or user transaction ac- 
count. Instead the merchant system receives a proxy code, 
which takes the place of that sensitive information ordi- 
narily received during transaction completion. In other 
words, certain information such as the user's actual ac- 
count number is never transmitted to the merchant. Thus, 
the user's account number is not available should the 
merchant system be compromised. 

[0015] | n accordance with one exemplary embodiment of the in- 
vention, a radio frequency identification (RFID) transaction 
device is used to complete a transaction. The RFID trans- 
action device may be interrogated by a RFID reader opera- 
ble to provide a RF interrogation signal for powering a 
transponder system. The RFID reader may receive the 



proxy code instead of sensitive transaction device infor- 
mation, and the merchant may receive the transaction de- 
vice proxy code from the RFID transaction device and pro- 
vide the proxy code to an authorizing agent, such as an 
acquirer or an account issuer, for verification. For exam- 
ple, the authorizing agent may verify that the proxy code 
corresponds to a valid transaction account on the account 
provider system. The authorizing agent may use the proxy 
code to locate the appropriate verifying (e.g., "validating") 
information for confirming the transaction account valid- 
ity. Once the authorizing agent verifies the validity of the 
transaction account using the proxy code, the authorizing 
entity (e.g., account issuer or acquirer) may provide au- 
thorization to the merchant that a transaction may be 
completed. 

[0016] | n one exemplary embodiment, the RFID reader may addi- 
tionally be validated. In this instance, the RFID reader may 
be provided a RFID reader authentication tag which may 
be used to validate the reader. During a transaction com- 
pletion, the RFID reader receives the RFID transaction de- 
vice proxy code, the reader may provide the transaction 
device proxy code, and the reader authentication tag to an 
authorizing agent, such as an acquirer. In similar manner 



as with the transaction account, the acquirer may then 
validate that the RFID reader is an authorized reader for 
facilitating a RF transaction with the account issuer. If the 
RFID reader is validated, the acquirer may then provide 
the RFID transaction device identifier to an account 
provider for RFID device verification. The account issuer 
may then verify that the RFID transaction device is autho- 
rized to complete the requested transaction. Alternatively, 
the reader may be directly validated by the account issuer. 
[0017] These features and other advantages of the system and 
method, as well as the structure and operation of various 
exemplary embodiments of the system and method, are 

described below. 
Brief Description of Drawings 

[0018] The accompanying drawings, wherein like numerals depict 
like elements, illustrate exemplary embodiments of the 
present invention, and together with the description, serve 
to explain the principles of the invention. In the drawings: 

[0019] FIG. 1 illustrates an exemplary RFID transaction system 

depicting exemplary components for use in a secure RFID 
transaction completed in accordance with the present in- 
vention; and 

[0020] FIG. 2 depicts an exemplary flowchart of an overview of a 



exemplary method for securing a RFID transaction in ac- 
cordance with the present invention. 
Detailed Description 

[0021] The present invention may be described herein in terms of 
functional block components, screen shots, optional se- 
lections and various processing steps. Such functional 
blocks may be realized by any number of hardware and/or 
software components configured to perform the specified 
functions. For example, the present invention may employ 
various integrated circuit components (e.g., memory ele- 
ments, processing elements, logic elements, look-up ta- 
bles, and the like), which may carry out a variety of func- 
tions under the control of one or more microprocessors or 
other control devices. Similarly, the software elements of 
the present invention may be implemented with any pro- 
gramming or scripting language such as C, C+ + , Java, 
COBOL, assembler, PERL, extensible markup language 
(XML), JavaCard and MULTOS with the various algorithms 
being implemented with any combination of data struc- 
tures, objects, processes, routines or other programming 
elements. Further, it should be noted that the present in- 
vention may employ any number of conventional tech- 
niques for data transmission, signaling, data processing, 



network control, encryption and the like. For a basic in- 
troduction on cryptography, review a text written by Bruce 
Schneier entitled "Applied Cryptography: Protocols, Algo- 
rithms, and Source Code in C," published by John Wiley & 
Sons (second edition, 1996), herein incorporated by refer- 
ence. 

[0022] The exemplary network disclosed herein may include any 
system for exchanging data or transacting business, such 
as the Internet, an intranet, an extranet, WAN, LAN, satel- 
lite communications, and/or the like. It is noted that the 
network may be implemented as other types of networks, 
such as an interactive television network (ITN). Further 
still, the terms "Internet" or "network" may refer to the In- 
ternet, any replacement, competitor or successor to the 
Internet, or any public or private inter-network, intranet 
or extranet that is based upon open or proprietary proto- 
cols. Specific information related to the protocols, stan- 
dards, and application software utilized in connection with 
the Internet may not be discussed herein. For further in- 
formation regarding such details, see, for example, Dilip 
Naik, "Internet Standards and Protocols" (1998); "Java 2 
Complete", various authors, (Sybex 1999); Deborah Ray 
and Eric Ray, "Mastering HTML 4.0" (1997); Loshin, "TCP/ 



IP Clearly Explained" (1997). All of these texts are hereby 
incorporated by reference. 

[0023] By communicating, a signal may travel to/from one com- 
ponent to another. The components may be directly con- 
nected to each other or may be connected through one or 
more other devices or components. The various coupling 
components for the devices can include but are not lim- 
ited to the Internet, a wireless network, a conventional 
wire cable, an optical cable or connection through air, wa- 
ter, or any other medium that conducts signals, and any 
other coupling device or medium. 

[0024] where required, the system user may interact with the 

system via any input device such as, a keypad, keyboard, 
mouse, biometric device, kiosk, personal digital assistant, 
handheld computer (e.g., Palm Pilot®, Blueberry®), cellular 
phone and/or the like. Similarly, the invention could be 
used in conjunction with any type of personal computer, 
network computer, work station, minicomputer, main- 
frame, or the like, running any operating system such as 
any version of Windows, Windows NT, Windows 2000, 
Windows 98, Windows 95, MacOS, OS/2, BeOS, Linux, 
UNIX, Solaris, or the like. Moreover, it should be under- 
stood that the invention could be implemented using 



TCP/IP communications protocol, SNA, IPX, Appletalk, 
IPte, NetBIOS, OSI or any number of communications pro- 
tocols. Moreover, the transactions discussed herein may 
include or result in the use, sale, or distribution of any 
goods, services or information over any network having 
similar functionality described herein. 
[0025] a variety of conventional communications media and pro- 
tocols may be used for data links providing physical con- 
nections between the various system components. For ex- 
ample, the data links may be an Internet Service Provider 
(ISP) configured to facilitate communications over a local 
loop as is typically used in connection with standard mo- 
dem communication, cable modem, dish networks, ISDN, 
Digital Subscriber Lines (DSL), or any wireless communi- 
cation media. In addition, the merchant system including 
a merchant point of sale (POS) device and host network 
may reside on a local area network, which interfaces to a 
remote network for remote authorization of an intended 
transaction. The POS may communicate with the remote 
network via a leased line, such as a Tl, D3 line, or the 
like. Such communications lines are described in a variety 
of texts, such as, "Understanding Data Communications," 
by Gilbert Held, which is incorporated herein by reference. 



[0026] a transaction device identifier, as used herein, may in- 
clude any identifier for a transaction device, such as, for 
example, any hardware, software, code, number, letter, 
symbol, digital certificate, smart chip, digital signal, ana- 
log signal, biometric and/or other identifier/indicia. The 
device identifier may also be correlated to a user transac- 
tion account (e.g., credit, charge debit, checking, savings, 
reward, loyalty, or the like) maintained by a transaction 
account provider (e.g., payment authorization center). A 
typical transaction account identifier (e.g., account num- 
ber) distinct to a transaction device, may be correlated to 
a credit or debit account, loyalty account, or rewards ac- 
count maintained and serviced by such entities as Ameri- 
can Express®, Visa®, MasterCard® or the like. 

[0027] a transaction device identifier or account number may be, 
for example, a sixteen-digit credit card number, although 
each credit provider has its own numbering system, such 
as the fifteen-digit numbering system used by American 
Express. Each company's credit card numbers comply with 
that company's standardized format such that the com- 
pany using a sixteen-digit format will generally use four 
spaced sets of numbers, as represented by the number 
"0000 0000 0000 0000." In a typical example, the first 



five to seven digits are reserved for processing purposes 
and identify the issuing bank, card type and, etc. In this 
example, the last sixteenth digit is used as a sum check 
for the sixteen-digit number. The intermediary eight- 
to-ten digits are used to uniquely identify the customer. 
The account number transaction device may be stored as 
Track 1 and Track 2 data as defined in ISO/IEC 7813, and 
further may be created unique to the RFID transaction de- 
vice. The account number or transaction device may be 
communicated in Track 1 and Track 2 data, as well. 
[0028] | n one exemplary embodiment, the transaction device may 
be correlated with a unique RFID transaction device ac- 
count number. In accordance with the invention, the ac- 
count number is not provided to a merchant during trans- 
action completion. Instead, the merchant system may be 
provided a "proxy code" (described below). The transac- 
tion device proxy code may be stored on a transaction de- 
vice database located on the transaction device. The 
transaction device database may be configured to store 
multiple proxy codes issued to the RFID transaction device 
user by the same or different account providing institu- 
tions. 

[0029] jo facilitate understanding, the present invention may be 



described with respect to a credit account. However, it 
should be noted that the invention is not so limited. Other 
accounts which facilitate an exchange of goods or services 
are contemplated to be within the scope of the present in- 
vention. 

[0030] The databases discussed herein may be any type of 

database, such as relational, hierarchical, object-oriented, 
and/or the like. Common database products that may be 
used to implement the databases include DB2 by IBM 
(White Plains, New York), any of the database products 
available from Oracle Corporation (Redwood Shores, Cali- 
fornia), Microsoft Access or MSSQL by Microsoft Corpora- 
tion (Redmond, Washington), or any other database prod- 
uct. Databases may be organized in any suitable manner, 
including as data tables or lookup tables. Association of 
certain data may be accomplished through any data asso- 
ciation technique known and practiced in the art. For ex- 
ample, the association may be accomplished either manu- 
ally or automatically. Automatic association techniques 
may include, for example, a database search, a database 
merge, GREP, AGREP, SQL, and/or the like. The association 
step may be accomplished by a database merge function, 
for example, using a "key field" in each of the manufac- 



turer and retailer data tables. A "key field" partitions the 
database according to the high-level class of objects de- 
fined by the key field. For example, a certain class may be 
designated as a key field in both the first data table and 
the second data table, and the two data tables may then 
be merged on the basis of the class data in the key field. 
In this embodiment, the data corresponding to the key 
field in each of the merged data tables is preferably the 
same. However, data tables having similar, though not 
identical, data in the key fields may also be merged by us- 
ing AGREP, for example. 
[0031] | n accordance with one aspect of the present invention, 
any suitable data storage technique may be utilized to 
store data without a standard format. Data sets may be 
stored using any suitable technique, including, for exam- 
ple, storing individual files using an ISO/IEC 7816-4 file 
structure; implementing a domain whereby a dedicated 
file is selected that exposes one or more elementary files 
containing one or more data sets; using data sets stored 
in individual files using a hierarchical filing system; data 
sets stored as records in a single file (including compres- 
sion, SQL accessible, hashed via one or more keys, nu- 
meric, alphabetical by first tuple, etc.); block of binary 



(BLOB); stored as ungrouped data elements encoded using 
ISO/IEC 7816-6 data elements; stored as ungrouped data 
elements encoded using ISO/IEC Abstract Syntax Notation 
(ASN.l) as in ISO/IEC 8824 and 8825; and/or other pro- 
prietary techniques that may include fractal compression 
methods, image compression methods, etc. 
[0032] | n one exemplary embodiment, the ability to store a wide 
variety of information in different formats is facilitated by 
storing the information as a Block of Binary (BLOB). Thus, 
any binary information can be stored in a storage space 
associated with a data set. As discussed above, the binary 
information may be stored on the financial transaction in- 
strument or external to but affiliated with the financial 
transaction instrument. The BLOB method may store data 
sets as ungrouped data elements formatted as a block of 
binary via a fixed memory offset using either fixed stor- 
age allocation, circular queue techniques, or best prac- 
tices with respect to memory management (e.g., paged 
memory, least recently used, etc.). By using BLOB meth- 
ods, the ability to store various data sets that have differ- 
ent formats facilitates the storage of data associated with 
the financial transaction instrument by multiple and unre- 
lated owners of the data sets. For example, a first data set 



which may be stored may be provided by a first issuer, a 
second data set which may be stored may be provided by 
an unrelated second issuer, and yet a third data set which 
may be stored, may be provided by an third issuer unre- 
lated to the first and second issuer. Each of these three 
exemplary data sets may contain different information 
that is stored using different data storage formats and/or 
techniques. Further, each data set may contain subsets of 
data which also may be distinct from other subsets. 

[0033] | n addition to the above, the transaction device identifier 
may be associated with any secondary form of identifica- 
tion configured to allow the consumer to interact or com- 
municate with a payment system. For example, the trans- 
action device identifier may be associated with, for exam- 
ple, an authorization/access code, personal identification 
number (PIN), Internet code, digital certificate, biometric 
data, and/or other secondary identification data used to 
verify a transaction device user identity. 

[0034] | t should be further noted that conventional components 
of RFID transaction devices may not be discussed herein 
for brevity. For example, one skilled in the art will appre- 
ciate that the RFID transaction device and the RFID reader 
disclosed herein include traditional transponders, anten- 



nas, protocol sequence controllers, modulators/de- 
modulators and the like, necessary for proper RFID data 
transmission. A suitable RFID transaction device and RFID 
reader which may be used with this invention are dis- 
closed in U.S. Patent Application No. 10/192,488, filed 
July 9, 2002. As such, those components are contem- 
plated to be included in the scope of the invention. 

[0035] Various components may be described herein in terms of 
their "validity." In this context, a "valid" component is one 
that is partially or fully authorized for use in completing a 
transaction request in accordance with the present inven- 
tion. Contrarily, an "invalid" component is one that is not 
partially or fully authorized for transaction completion. 

[0036] Although the present invention is described with respect 
to validating a transaction device or reader communicat- 
ing in a RF transaction, the invention is not so limited. The 
present invention may be used for any device, machine, or 
article which provides user identifying data to a merchant. 
Thus, the present invention may be used in any contact or 
contactless environment where identifying data is trans- 
ferred to a merchant. 

[0037] During a typical RFID transaction, a RFID transaction de- 
vice user may transmit information concerning the user's 



transaction account to a merchant POS. The information 
received by the POS may include, for example, the trans- 
action device identifier or account number. The informa- 
tion may further include personal, demographic, biometric 
or statistical information related to the transaction device 
user. Upon receiving the information, the merchant POS 
ordinarily provides the information to a merchant system. 
The merchant may store the information in a merchant 
system database for later reference. For example, the 
merchant system may then reference the transaction de- 
vice information in the event that a user wishes to com- 
plete a transaction by providing the merchant the same 
identifying information as the merchant has stored on the 
merchant system. 
[0038] | n m ost instances, the transaction device information is 
stored on the merchant system database for an extended 
period of time. The extended storage is often because the 
merchant typically may wish to have the information read- 
ily available for later reference (e.g., transaction request 
maintenance, account or transaction request tracking, or 
the like). The merchant may also desire to archive the 
transaction device information for later use in preparing 
promotional offers or solicitations or materials to be pro- 



vided to the transaction device user. 
[0039] one key disadvantage of the conventional transaction 

processing method described above is that the informa- 
tion stored by the merchant is typically "sensitive infor- 
mation." Sensitive information is that information which 
the transaction account provider or the transaction device 
user would want to guard from theft. Sensitive informa- 
tion may be any information or data. The sensitive infor- 
mation may be used to conduct a fraudulent transaction. 
For example, sensitive information may be the user ac- 
count number, transaction device identifier, transaction 
device user personal data or the like. The information may 
be used for example to complete a transaction by repro- 
ducing the sensitive information without authorization. If 
sensitive information is somehow compromised or stolen, 
it is easily subjected to fraudulent usage. For example, 
should an unscrupulous person gain access to the mer- 
chant system and steal the transaction device identifier or 
account number, the person may be able to use the stolen 
information to place fraudulent charges on the associated 
transaction account. As such, the merchant may put into 
place special security measures designed to protect the 
sensitive information from theft. The merchant ordinarily 



makes decisions related to securing the sensitive informa- 
tion without consulting the account provider. The transac- 
tion account provider often must rely on the effectiveness 
of the merchant security measures to ensure that the in- 
formation is not stolen while being stored on the mer- 
chant database. If the merchant security methods are in- 
effective or easily compromised, the sensitive information 
may be easily stolen. 
[0040] The present system and method permits the account is- 
suer to control the level of security with which the infor- 
mation stored on the merchant database is protected. An 
exemplary method in accordance with the present inven- 
tion is described in FIG. 2. In accordance with the inven- 
tion, an account provider provides a transaction account 
to an account user for completing a transaction (step 
202). The user may receive the transaction account after 
the user provides information concerning the user to an 
account provider system. For example, the user may com- 
plete an application for a credit card, and the credit card 
provider may provide a credit transaction account to the 
user for transaction completion. The account issuer may 
then permanently assign a proxy code to the transaction 
account, so that the proxy code need never be altered or 



modified during the life of the transaction account (step 
204). The account issuer may store the proxy code correl- 
ative to the related transaction account. The account is- 
suer may store the proxy code and the account number in 
a relational database, so that the account issuer could lo- 
cate the transaction account by referencing the associated 
permanently assigned proxy code. The account provider 
may then provide the proxy code to the user, by embody- 
ing the proxy code in any presentable form factor such as 
a credit card, debit card, calling card, loyalty card, key 
fob, cell phone, key ring, ring, or the like (step 206). The 
user may then provide the proxy code to a merchant sys- 
tem during the completion of a transaction request (step 
208). The manner in which the user provides the transac- 
tion account proxy code to the user system may vary in 
accordance with the form factor in which the proxy is em- 
bodied. For example, where the proxy code is embodied 
in the magnetic stripe of a conventional credit card, the 
user may provide the proxy code to the merchant by 
"swiping" the magnetic stripe at a suitable reader as is 
found in the prior art. Alternatively, the proxy code may 
be embodied in a transponder system associated with a 
key fob. In this instance the user may provide the account 



number to the merchant system by waiving the key fob in 
proximity to a suitable transponder reader. The reader 
may provide an interrogation signal to the transponder 
system to facilitate operation of the transponder system 
and the transponder reader may provide the proxy code to 
the merchant system for processing. The merchant may 
receive the proxy code and store the proxy code in a mer- 
chant system database for later reference (step 210). For 
example, where the user requests that the merchant store 
the proxy code in reference to a recurring billing account 
for payment, the merchant may store the proxy code rela- 
tive to the recurring billing account and periodically use 
the proxy code to seek payment. The merchant system 
may then provide the proxy code to the account issuer in 
a transaction request, under the merchant defined busi- 
ness as usual standard to facilitate completing the trans- 
action (step 212). The account issuer may receive the 
proxy code and match the proxy code to the correspond- 
ing transaction account, which may be stored on a mer- 
chant database (step 214). The account provider may then 
provide to the merchant the information, or funds to 
complete the transaction (216). 
[0041] a s usec | herein, the term "proxy code" may include any 



device, hardware, software, code, number, letter, symbol, 
digital certificate, smart chip, digital signal, analog signal, 
biometric and/or other identifier/indicia. The proxy code 
may also refer to any information provided to, for exam- 
ple, a merchant system during completion of a transaction 
request, which partially or fully masks the underlying sen- 
sitive information from the merchant system. As such, the 
information provided "masks" the underlying sensitive in- 
formation related to the transaction account from the 
merchant system. Particularly, the information provided to 
the merchant (called "proxy code", herein) does not in- 
clude sensitive information like, for example, the transac- 
tion account number. Consequently, the merchant system 
is never provided the sensitive information since the sen- 
sitive information is not included in the proxy code. More- 
over, the proxy code may take the form of any conven- 
tional transaction account identifier. As such, when the 
merchant receives the proxy code, the merchant system 
may process the proxy code under business as usual 
standards. For example, the proxy code may take the 
form of any conventional transaction device identifier or 
account number. The merchant system thereby stores the 
proxy code in the place of the information ordinarily 



stored under conventional processing methods. Since the 
proxy code does not include sensitive information, no 
sensitive information may be stolen should the merchant 
system be compromised. In this way, the account issuer 
may substantially eliminate, minimize or control the risks 
associated with the security of the merchant system being 
compromised (e.g., fraud transactions, identity theft, etc.). 

[0042] Another advantage of the present invention is that since 
the proxy code is permanently associated to a transaction 
account, the proxy code need never be modified in the 
merchant system. As such, the present invention elimi- 
nates the need to update information on the merchant 
system every time the related transaction device is lost, 
stolen, or replaced. More particularly, the replacement de- 
vice is provided the identical proxy code as was provided 
to the original transaction device. Consequently, the mer- 
chant is provided the identical proxy code in any instance 
where the user wishes to complete a transaction using the 
transaction account which the account provider has per- 
manently associated with the proxy code. 

[0043] For example, the merchant may receive the proxy code 

and store the proxy code related to a recurring billing ac- 
count such as a telephone account. Periodically the mer- 



chant may bill a transaction device user in accordance 
with the telephone services provided. The device user may 
wish to provide the merchant with transaction device in- 
formation the merchant may use to satisfy the bill. The 
user may authorize the merchant to store the device in- 
formation for repeated use in satisfying the bill. In a con- 
ventional recurring billing environment, the device infor- 
mation must ordinarily be updated when the user loses 
the device or the device information expires. That is, the 
replacement device often is given device information 
which is often different from the information contained on 
the original transaction device. However, in accordance 
with the present invention, the merchant need not update 
transaction device information because the proxy code is 
permanently associated with the transaction account. 
[0044] FIG. 1 illustrates an exemplary RFID transaction system 

100 in accordance with the present invention, wherein ex- 
emplary components for use in completing a RF transac- 
tion are depicted. In general, system 100 may include a 
RFID transaction device 102 in RF communication with a 
RFID reader 104 for transmitting data therebetween. The 
RFID reader 104 may be in further communication with a 
merchant point of sale (POS 106) device 106 for providing 



to the POS 106 information received from the RFID trans- 
action device 102. The POS 106 may be in further com- 
munication with a merchant system 101, which may in- 
clude a merchant database 103. Merchant system 101 
may be in communication with an acquirer 110 or an ac- 
count issuer 112 via a network 108 for transmitting trans- 
action request data and receiving authorization concern- 
ing transaction completion. 
[0045] Although the POS 106 is described herein with respect to 
a merchant point of sale (POS) device, the invention is not 
to be so limited. Indeed, a merchant POS device is used 
herein by way of example, and the point of sale device 
may be any device capable of receiving transaction device 
account information from the transaction device 102. In 
this regard, the POS 106 may be any point of interaction 
device, such as, for example, a merchant terminal, kiosk, 
user terminal, computer terminal, input/output receiver or 
reader, etc., enabling the user to complete a transaction 
using a transaction device 102. The POS device 106 may 
receive RFID transaction device 102 information and pro- 
vide the information to a merchant system 101 for pro- 
cessing. 

[0046] As used herein, an "acquirer" may be any databases and 



processors (e.g., operated by a third party) for facilitating 
the routing of a payment request to an appropriate ac- 
count issuer 112. The acquirer 110 may route the pay- 
ment request to the account issuer 112 in accordance 
with a routing number, wherein the routing number cor- 
responds to the account issuer 112. The routing number 
may be provided by the RFID transaction device 102. The 
"routing number" in this context may be a unique network 
address or any similar device for locating an account is- 
suer 112 on a network 108. In one exemplary embodi- 
ment, the routing number may typically be stored on one 
of the "tracks" comprising a magnetic stripe network. For 
example, the proxy code may be provided in traditional 
ISO magnetic stripe format. The routing number may be 
typically stored in Track 1 / Track 2 format so that the in- 
formation may be interpreted by the POS device 106 and 
merchant system 101. Traditional means of routing the 
payment request in accordance with the routing number 
are well understood. As such, the process for using a 
routing number to provide a payment request will not be 
discussed herein. 
[0047] | n addition, the account issuer 112 (or account provider) 
may be any entity which provides a transaction account 



useful for facilitating completion of a transaction request. 
The transaction account may be any account which main- 
tains credit, debit, loyalty, direct debit, checking, savings, 
or the like. The term "issuer" or "account provider" may 
refer to any entity facilitating payment of a transaction 
using a transaction device, and which may include sys- 
tems permitting payment using at least one of a 
preloaded and non-preloaded transaction device 102. 
Typical issuers may be American Express, MasterCard, 
Visa, Discover, and the like. 
[0048] | n general, during operation of system 100, the RFID 

reader 104 may provide an interrogation signal to trans- 
action device 102 for powering the device 102 and receiv- 
ing transaction device related information. The interroga- 
tion signal may be received at the transaction device an- 
tenna 120 and may be further provided to a transponder 
(not shown). In response, the transaction device processor 
114 may retrieve transaction device information from 
transaction device database 116 for providing to the RFID 
reader 104 to complete a transaction request. Typically, 
where the transaction device information includes a trans- 
action device identifier or authentication tag, the identifier 
and tag may be encrypted prior to providing the informa- 



tion to reader 104. 

[0049] | t should be noted that the RFID reader 104 and the RFID 
transaction device 102 may engage in mutual authentica- 
tion prior to transferring any transaction device 102 data 
to the reader 104. For a detailed explanation of a suitable 
mutual authentication process for use with the invention, 
see commonly owned U.S. Patent Application No. 
10/340,352, entitled "System and Method for Incenting 
Payment Using Radio Frequency Identification in Contact 
and Contactless Transactions," filed January 10, 2003, in- 
corporated by reference in its entirety. 

[0050] Once the RFID reader 104 receives the transaction device 
information, the reader 104 provides the information to 
the merchant POS 106 which provides the information to 
the merchant system 101. The merchant system 101 may 
then append the transaction device information with 
transaction request data and provide the entire transac- 
tion request (i.e., transaction request data and transaction 
device information) to an acquirer 110 or issuer 112 for 
transaction completion. The transmitting of the informa- 
tion from the transaction device 102 to the acquirer 110 
(or issuer 112) may be accomplished in accordance with 
any conventional method for completing a transaction us- 



ing contact and wireless data transmission. The acquirer 
110 or the issuer 112 may then determine whether to au- 
thorize completion of the transaction request in accor- 
dance with any business as usual protocol. 
[0051] | n addition to appending the transaction device informa- 
tion to the transaction request data for transaction autho- 
rization, conventional merchant systems may also store 
the transaction device information in a merchant system 
database (not shown) for later reference. For example, a 
particular merchant may want to provide special adver- 
tisements to the user of the transaction device 102 based 
on the user's prior purchases at the merchant location. 
The merchant system 101 may then recall the transaction 
device information and use the information to prepare, for 
example, a repeat customer mailing list. In some cases, 
however, the merchant system 101 often also stores sen- 
sitive information related to the user such as, for exam- 
ple, the user's account number (e.g., credit card number) 
associated with the transaction device 102. This sort of 
information is typically very easy to use in fraudulent 
transactions and therefore must be secured from theft. As 
such, conventional merchant systems use special security 
methods to safeguard the sensitive information from 



theft. 

[0052] The account issuer 112 may provide additional security by 
assigning a permanent fixed proxy code to the transaction 
device transaction account (step 204 of FIG. 2). The proxy 
code may not itself include sensitive information. The 
proxy code may be associated with a user's transaction 
account number on a merchant database 103. The ac- 
count issuer 112 may then provide the proxy code, and 
not the transaction account number, to the user in a suit- 
able form factor such as, the RFID transaction device 102 
discussed above (step 208). The transaction device 102 
user may then provide the proxy code to the merchant 
system 101 during the completion of transaction (step 
208). The merchant system 101 may then process the 
proxy code as a part of a transaction request and may 
provide the proxy code and to the account issuer 112 for 
process under merchant and account issuer business as 
usual standards (step 212). The merchant system 101 
may also store the account proxy code for later reference 
(step 210). Since the proxy code is permanently assigned 
to the transaction account, the merchant system never 
need to modify the proxy code on the merchant system 
101. The merchant system 101 may store the proxy num- 



ber on merchant database 103 using any method the 
merchant ordinarily uses to store customer data. 

[0053] | n assigning the proxy code, the issuer system 112 may 

first permit a transaction device 102 user to open a trans- 
action account for use in completing a transaction request 
(step 202). The user may open a transaction account by 
providing personal or demographic information and the 
like to an issuer system 112 which may use the informa- 
tion to assign a transaction account and account number 
to the user. The transaction account may be identified by 
the account number in the issuer system 112 database 
(not shown), and the issuer system 112 may be able to 
reference the transaction account using the account num- 
ber when authorizing a transaction (step 214). 

[0054] | n t his context, the account number is considered sensi- 
tive information. The issuer system 112 may then assign a 
proxy code to the transaction account (step 220). In as- 
signing the proxy code, the issuer system 112 may corre- 
late or match the proxy code to the account number in, 
for example, a relational database. The algorithm may be 
such that it will receive the proxy code and operate on the 
proxy code to convert the proxy code to a number corre- 
lated with the transaction account number. Alternatively, 



the account issuer 112 may store the proxy code in a one 
to one relationship with the account number. Further still, 
the account issuer 112 may use any suitable correlation 
technique that is known which permits the account issuer 
system to receive one data and associate it with a second 
data. In other embodiments, the proxy code may be de- 
rived from the account number or any other data field, 
where the proxy code is store, for example, in data fields 
on the transaction device 102. Where the proxy code is 
accompanied by a secondary identifier, such as, for exam- 
ple, a personal identification number (PIN), the issuer sys- 
tem 112 database may correlate or match the proxy code, 
account number and secondary identifier, so that the is- 
suer system 112 may reference anyone of the numbers 
using any one of the other numbers. The issuer system 
112 may use any conventional matching or storage proto- 
col as is found in the art. 
[0055] | n one exemplary embodiment, the issuer system 112 may 
assign distinct proxy codes for each transaction account 
the issuer system 112 maintains. In which case, no two 
transaction accounts would be assigned identical proxy 
codes. In another exemplary embodiment, the issuer sys- 
tem 112 may assign the same proxy code to a plurality of 



transaction accounts, to multiple accounts related to the 
same cardholder, to multiple accounts controlled by the 
same entity (e.g., corporate card accounts), to all the 
transaction accounts the issuer system 112 maintains or 
any other subset of accounts. Moreover, a proxy code may 
not be a separate code; rather, the proxy code may be de- 
rived from the transaction device identifier or any other 
data. In another embodiment, the proxy code may be 
contained within another code or account number. In an- 
other embodiment, the proxy code is an encrypted or ma- 
nipulated account number (or any other sensitive infor- 
mation). The same proxy code, an amended proxy code or 
an additional proxy code may also represent other sensi- 
tive data (aside from the account number), such as, for 
example, account holder name, address, biometric infor- 
mation, demographic information and/or the like. In this 
regard, the merchant system will not have access to this 
information, but the proxy code related to this informa- 
tion will be sent to the acquirer when the acquirer re- 
quires any portion of this information as part of its ap- 
proval process. 

[0056] The proxy code is then loaded onto the transaction de- 
vice. In other embodiments, the device may generate its 



own proxy code. In this embodiment, the user may down- 
load the generated proxy code to the issuer (e.g., via the 
Internet) prior to using the code in a transaction. In an- 
other embodiment, the reader, POS or merchant system 
may generate a proxy code prior to, during or after re- 
ceiving sensitive information. In this embodiment, the 
reader may delete the sensitive information, and only 
transmit the proxy code to complete the transaction. 
[0057] while the transaction device may only contain the proxy 
code, in certain embodiments, the transaction device may 
also contain the account number and other sensitive data; 
however, the transaction device will only communicate the 
proxy code to the reader. In one exemplary embodiment, 
the proxy code is configured in magnetic stripe format. 
That is, the proxy code may be stored in the Track 1 / 
Track 2 portions of the magnetic stripe track network. The 
proxy code may be uploaded onto a transaction device 
102 which the account issuer 112 has assigned to a user 
(step 230). The proxy code may be uploaded into the 
transaction device database in magnetic stripe format, 
and may also be transmitted to the merchant system 101 
in similar magnetic stripe format. A suitable method for 
providing the proxy code to the transaction device 102 



may be determined by the transaction device 102 config- 
uration. For example, conventional methods and magnetic 
stripe read/write devices may be used to encode the 
proxy code in one location on one of the magnetic stripe 
tracks. Alternatively, the proxy code may be uploaded into 
a database or other storage area contained on the trans- 
action device 102, by populating the proxy code on the 
database using any convention method. A suitable 
method is described in commonly owned U.S. Patent Ap- 
plication No. 10/192,488, entitled "SYSTEM AND METHOD 
FOR RFID PAYMENT USING RADIO FREQUENCY IDENTIFI- 
CATION IN CONTACT AND CONTACTLESS TRANSAC- 
TIONS," incorporated herein by reference. Once the proxy 
code is uploaded into the transaction account database, 
the transaction device 102 may be used for transaction 
completion (step 208). 
[0058] | n this embodiment, the transaction account may also be 
assigned a secondary form of identification which may be 
encrypted, and which may not be available to the mer- 
chant system 101. The secondary form of identification 
may be correlated to the transaction account on the issuer 
system 112 so that the issuer system 112 may later refer- 
ence the transaction account for transaction completion. 



[0059] Once the proxy code is assigned and loaded on the trans- 
action device, the proxy code may be provided during the 
execution of a transaction in lieu of the actual transaction 
account number. In this way, the proxy code masks the 
actual account number from the merchant system 101 
and from potential theft. Thus, instead of the merchant 
system 101 storing the account number for later refer- 
ence, the merchant system 101 stores the proxy code. 

[0060] As noted, in one exemplary embodiment, the proxy code 
is formatted to mimic conventional transaction device 
sensitive information, such as an account number. Be- 
cause the proxy code mimics an account number or any 
other sensitive data and is configured in a format recog- 
nizable to the merchant system 101, the merchant system 
101 is unable to distinguish between the proxy code and 
the actual account number. For example, where the actual 
account number is a credit card number, the proxy code 
would be configured to take the form of a valid credit card 
number. Similarly, where the actual account number is a 
loyalty number, the proxy code is configured in a format 
similar to a valid loyalty number. In either case, however, 
the proxy code may contain no or minimal sensitive infor- 
mation related to the user account. 



[0061] As shown, a secure RFID transaction in accordance with 
this embodiment may begin when the RFID device 102 
enters the interrogation zone of the RFID reader 104 and 
is interrogated, such as when the transaction device 102 
is used to complete a transaction request (step 208). The 
transaction device 102 information, including the proxy 
code, device 102 encrypted identifier (where included), 
and the account issuer 112 routing number, may then be 
provided to the device processor 114 for transmitting to 
the RFID reader 104 via RF transmission. 

[0062] The RFID reader 104 may receive the transaction device 
102 information, including the proxy code, and if neces- 
sary, convert the information into a POS recognizable for- 
mat. The converted information may then be provided to 
the merchant system 101 via POS 106. The merchant sys- 
tem 101 may receive the transaction device information 
and combine the information with information concerning 
the requested transaction to produce a transaction re- 
quest. The transaction information may include a product 
or merchant location identifier, as well as the terms for 
satisfying the transaction (e.g., price to be paid, barter 
points to be traded, loyalty points to be redeemed). Be- 
cause the proxy code is in the same format as the account 



number or other sensitive data, the merchant system rec- 
ognizes the information as valid data for the respective 
field. The merchant system may then provide the transac- 
tion request to an acquirer 110 via a network 108 for 
transaction request completion. 

[0063] The acquirer 110 may, in turn, provide the transaction re- 
quest to the appropriate account issuer 112 for process- 
ing (step 212). The acquirer 110 may identify the appro- 
priate account issuer 112 using the routing number pro- 
vided by the transaction device 102 to locate the network 
address corresponding to the account issuer 112, thereby 
permitting the acquirer 110 to provide the transaction re- 
quest to the account issuer 112 maintaining the corre- 
sponding transaction device account. 

[0064] The account issuer 112 may receive the transaction re- 
quest and process the transaction request in accordance 
with the issuer system defined protocol. 

[0065] The preceding detailed description of exemplary embodi- 
ments of the invention makes reference to the accompa- 
nying drawings, which show the exemplary embodiment 
by way of illustration. While these exemplary embodi- 
ments are described in sufficient detail to enable those 
skilled in the art to practice the invention, it should be 



understood that other embodiments may be realized and 
that logical and mechanical changes may be made without 
departing from the spirit and scope of the invention. In 
addition, the steps recited in any of the method or pro- 
cess claims may be executed in any order and are not lim- 
ited to the order presented or method steps may be 
added or eliminated as desired. Further, the present in- 
vention may be practiced using one or more servers, as 
necessary. Thus, the preceding detailed description is 
presented for purposes of illustration only and not of lim- 
itation, and the scope of the invention is defined by the 
preceding description, and with respect to the attached 
claims. 



